English+GermanWikipedia - /page/entry.mu

Micron Document

<!DOCTYPE html>

<title>Refactoring</title>

</head>

<h1 id="firstHeading" class="firstHeading mw-first-heading">Refactoring</h1>

</header>

</div>

<div id="mw-content-text" class="mw-body-content mw-content-ltr" lang="de" dir="ltr"><div class="mw-content-ltr mw-parser-output" lang="de" dir="ltr">Refactoring (auch Refaktorisierung, Refaktorierung oder Restrukturierung) bezeichnet in der <a href="Software-Entwicklung" class="mw-redirect" title="Software-Entwicklung">Software-Entwicklung</a> die manuelle oder automatisierte Strukturverbesserung von <a href="Quelltext" title="Quelltext">Quelltexten</a> unter Beibehaltung des beobachtbaren Programmverhaltens. Dabei sollen <a href="Lesbarkeit" title="Lesbarkeit">Lesbarkeit</a>, Verständlichkeit, <a href="Wartbarkeit" title="Wartbarkeit">Wartbarkeit</a> und Erweiterbarkeit verbessert werden, mit dem Ziel, den jeweiligen Aufwand für <a href="Fehler#Fehleranalyse_und_Fehlerbereinigung" title="Fehler">Fehleranalyse</a> und funktionale Erweiterungen deutlich zu senken.

Refactoring ist ein zentraler Bestandteil der <a href="Agile_Softwareentwicklung" title="Agile Softwareentwicklung">Agilen Softwareentwicklung</a>. Dort wird meist von „kontinuierlichem“ Refactoring<a href="#cite_note-1">[1]</a> oder „kompromisslosem“ Refactoring<a href="#cite_note-2">[2]</a> gesprochen. Refactoring ist in der agilen Softwareentwicklung wie Programmieren oder Modultesten ein integraler Bestandteil des Softwareentwicklungsprozesses und nicht auf bestimmte Zeiten bzw. Phasen beschränkt.

<div class="mw-heading mw-heading2"><h2 id="Begriffsherkunft">Begriffsherkunft</h2></div>

Der Begriff wurde zum ersten Mal in einer Arbeit von <a href="Ralph_Johnson" title="Ralph Johnson">Ralph Johnson</a> und William Opdyke 1990 gebraucht (Refactoring: An aid in designing application frameworks and evolving object-oriented systems. In: Proceedings of Symposion on Object-Oriented Programming Emphasizing Practical Applications (SOOPPA), September 1990). Opdyke promovierte 1992 zu dem Thema.

Sie entwickelten die Idee einer Software-Refactory, die das Umgestalten (eben das Refactoring) von Computerprogrammen erleichtern sollte.

Die unzutreffende Übersetzung Refaktorisierung stammt aus einer Verwechslung mit einer häufig zitierten Analogie, die ursprünglich nicht Begriffsinhalt war: Refactoring ist eine Art, ein Programm so zu modifizieren, dass verborgene Strukturen offengelegt werden, ohne die Funktionalität zu ändern. Dies, so der (fälschliche) <a href="Analogieschluss" class="mw-redirect" title="Analogieschluss">Analogieschluss</a>, entspreche dem Vorgehen der <a href="Faktorisierung_von_Polynomen" title="Faktorisierung von Polynomen">Faktorisierung von Polynomen</a> in der <a href="Mathematik" title="Mathematik">Mathematik</a>.

<div class="mw-heading mw-heading2"><h2 id="Vorgehensweise">Vorgehensweise</h2></div>

Refactoring wird hauptsächlich auf unschöne Stellen im Code (siehe <a href="Code-Smell" title="Code-Smell">Code-Smell</a>) angewandt. Dabei wird der Quelltext eines <a href="Computerprogramm" title="Computerprogramm">Computerprogramms</a> umgestaltet, wobei die tatsächliche Programmfunktion unverändert bleiben soll. Die Umgestaltung des Quelltextes erfolgt meist nach folgenden Gesichtspunkten:

<ul><li>Lesbarkeit</li>

<li>Übersichtlichkeit</li>

<li>Verständlichkeit</li>

<li>Erweiterbarkeit</li>

<li>Vermeidung von <a href="Code-Duplizierung" class="mw-redirect" title="Code-Duplizierung">Redundanz</a></li>

<li>Testbarkeit</li></ul>

Die Gesichtspunkte des Refactorings hängen eng mit den daraus resultierenden Vorteilen zusammen. Das Refactoring hat ein <a href="Analogie_(Philosophie)" title="Analogie (Philosophie)">Analogon</a> in der Mathematik in einer Vorgehensweise, die als <a href="Term#Algebraische_Umformungen" title="Term">algebraische Umformung</a> bezeichnet wird, bei der das Ziel der Umformung ebenfalls eine bessere Lesbarkeit, Verständlichkeit und gegebenenfalls Erweiterbarkeit (des Gleichungssystems) ist.

Aus diesem Grunde sind funktionale Sprachen (<a href="Lisp" title="Lisp">Lisp</a>, <a href="Haskell_(Programmiersprache)" title="Haskell (Programmiersprache)">Haskell</a>, <a href="OCaml" title="OCaml">OCaml</a>, <a href="Erlang_(Programmiersprache)" title="Erlang (Programmiersprache)">Erlang</a> und so weiter) wesentlich besser geeignet, ein Refactoring durchzuführen, da sie auf einem mathematischen Paradigma der Programmierung basieren.

Das Refactoring wird erleichtert und unterstützt durch:

<ul><li><a href="Unit-Test" class="mw-redirect" title="Unit-Test">Unit-Tests</a>, die als <a href="Regressionstest" title="Regressionstest">Regressionstests</a> belegen können, dass sich das Verhalten des Programmes unter gleichen Bedingungen nicht geändert hat und durch das Refactoring nicht versehentlich Fehler eingeführt wurden,</li>

<li>Werkzeuge, insbesondere <a href="Integrierte_Entwicklungsumgebung" title="Integrierte Entwicklungsumgebung">integrierte Entwicklungsumgebungen</a>, die eine Unterstützung bei der Durchführung von Refactorings anbieten,</li>

<li>funktionale Programmiersprachen (unter anderem, weil man Code bei funktionalen Sprachen mit mathematischen Methoden auf Korrektheit prüfen kann),</li>

<li>eine Programmiersprache mit einem strengen Typsystem (z. B. bei der Programmiersprache <a href="OCaml" title="OCaml">OCaml</a>), welches schon im Vorfeld (zur Compile-Time) viele Fehler ausschließt, weil es dafür sorgt, dass die Signatur (Interface) dieselbe bleibt, auch wenn die Struktur (Implementierung) sich ändert. Dies erspart viele Unit-Tests schon im Vorfeld (da es viele Fehlerquellen ausschließt).</li></ul>

Mögliche Refactorings

Folgende Maßnahmen oder Arbeiten werden beim Refactoring besonders häufig durchgeführt:

<ul><li>Änderung eines Symbolnamens, z. B. das Vergeben von sprechenden Namen für Variablen, Konstanten, Methoden etc.</li>

<li>Verschieben eines Symbols in ein anderes Modul, z. B. eine Methode in eine andere Klasse</li>

<li>Aufteilung eines Moduls (z. B. Paket, Klasse, Methode) in mehrere kleinere Module oder Zusammenlegung kleinerer Module zu einem größeren.</li>

<li>Im weitesten Sinne auch die Umformatierung eines Quelltextes, z. B. mit einem <a href="Beautifier" class="mw-redirect" title="Beautifier">Beautifier</a></li>

<li>Bei geänderten Geschäftsprozessen bei Darstellung mittels der Unified Modeling Language <a href="UML" class="mw-redirect" title="UML">UML</a> kann mittels „Refactoring“ der Programmcode geändert werden. Dadurch wird eine robuste und stabile <a href="Systemarchitektur" title="Systemarchitektur">Systemarchitektur</a> geschaffen, da unübersichtliche Änderungen nicht im Code initiiert werden müssen.</li>

<li>Anwenden von <a href="Funktion_h%C3%B6herer_Ordnung" title="Funktion höherer Ordnung">Funktionen höherer Ordnung</a> in funktionalen Programmiersprachen</li>

<li>Auslagern (refactor’n) der gemeinsamen abstrakten Logik mehrerer Module in Funktoren. (Funktoren sind parametrisierte Module, die Module als Parameter erhalten und Module als Ergebnis liefern.)</li>

<li>Zusammenfassen (Abstrahieren) zwei oder mehrerer generisch sehr ähnlicher Funktionalitäten zu einer allgemeingültigen Funktionalität (Reduzierung von mehrfach dupliziertem Code mit sehr hoher Ähnlichkeit)</li>

<li>Beseitigen von totem Code</li></ul>

<div class="mw-heading mw-heading2"><h2 id="Vorteile_und_Nachteile">Vorteile und Nachteile</h2></div>

<div class="mw-heading mw-heading3"><h3 id="Vorteile">Vorteile</h3></div>

Refactoring dient der Verbesserung der <a href="Wartbarkeit" title="Wartbarkeit">Wartbarkeit</a> des <a href="Softwaredesign" title="Softwaredesign">Designs</a> in der Art, dass es für den Programmierer leichter wird, den bestehenden Code funktional zu erweitern oder an anderer Stelle <a href="Wiederverwendung" title="Wiederverwendung">wiederzuverwenden</a>. Dies versucht man zu erreichen, indem man den Code insbesondere bezüglich folgender Kriterien verbessert:

<ul><li><a href="Lesbarkeit" title="Lesbarkeit">Lesbarkeit</a>, so dass möglichst viele Programmierer verstehen, was der Code tatsächlich macht</li>

<li><a href="Modul_(Software)" title="Modul (Software)">Modularität</a> und <a href="Redundanz_(Informationstheorie)" title="Redundanz (Informationstheorie)">Redundanz</a>, so dass konkrete Problemlösungen von anderer Stelle genutzt werden können und nicht mehrfach implementiert sind</li>

<li><a href="Kopplung_(Softwareentwicklung)" title="Kopplung (Softwareentwicklung)">Kopplung</a> und <a href="Koh%C3%A4sion_(Informatik)" title="Kohäsion (Informatik)">Kohäsion</a>, damit zukünftige Änderungen nur lokale Auswirkungen haben</li>

<li><a href="Testbarkeit" title="Testbarkeit">Testbarkeit</a> (siehe <a href="Unit-Test" class="mw-redirect" title="Unit-Test">Unit-Test</a>), so dass es möglich wird, die korrekte Arbeitsweise des Codes für die Zukunft durch <a href="Regressionstest" title="Regressionstest">Regressionstests</a> abzusichern</li></ul>

Im üblichen Softwareentwicklungszyklus ist ein fortwährender Kreislauf von <a href="Spezifikation" title="Spezifikation">Spezifikation</a>, <a href="Design" title="Design">Design</a>, <a href="Implementierung" title="Implementierung">Implementierung</a> und <a href="Softwaretest" title="Softwaretest">Tests</a> vorgesehen. Nach jedem Durchlauf kann das Softwareprodukt immer wieder neu in diesen Kreislauf einsteigen. Mit den klassischen Techniken hieß das jedoch, dass nach einer Änderung der Spezifikation oder einem Redesign oft Teile oder sogar das ganze Programm völlig neu geschrieben werden mussten. Refactoring erlaubt dem <a href="Softwareentwickler" title="Softwareentwickler">Entwickler</a>, diesen Zyklus permanent im Kleinen ablaufen zu lassen, und so sein Produkt kontinuierlich zu verbessern.

<div class="mw-heading mw-heading3"><h3 id="Nachteile">Nachteile</h3></div>

Je nach Umsetzung kann Refactoring auch einige Nachteile mit sich ziehen:

<ul><li>Durch das Refactoring können, wie bei jeder andern Codeänderung auch, neue, unerwartete Fehler entstehen.</li>

<li>Da Fehler entstehen können, entsteht (wenn die Regressionstests nicht automatisiert sind) Testaufwand für Regressionstests.</li>

<li>Neben allgemein gültigen <a href="Prinzipien_objektorientierten_Designs" title="Prinzipien objektorientierten Designs">Designprinzipien</a> kann Refactoring auch in Richtung spezifischer Designausprägungen gemacht werden, welche nicht der Verbesserung der Wiederverwendung dienen. In diesem Fall wäre das Refactoring Zeitverbrauch ohne wirklichen Nutzen für den Kunden, welcher von „wichtigeren Aufgaben“ ablenkt.</li></ul>

<div class="mw-heading mw-heading2"><h2 id="Risiken_und_deren_Handhabung">Risiken und deren Handhabung</h2></div>

Refactoring wird nur auf funktionierendem Code ausgeführt (dessen Funktionalität erhalten bleiben soll). Dies beinhaltet aber auch das <a href="Risiko" title="Risiko">Risiko</a> ungewünschter Änderungen und Fehler. Um dieses Risiko zu vermeiden (oder wenigstens zu minimieren) verwendet man verschiedene <a href="Regel_(Richtlinie)" title="Regel (Richtlinie)">Regeln</a>, die den Prozess des Refaktorisierens weniger gefährlich machen.

Zuerst sollte man eine Reihe automatisch ablaufender <a href="Unit-Test" class="mw-redirect" title="Unit-Test">Unit-Tests</a> haben. Diese werden vor dem Refactoring angewandt, und man beginnt erst, wenn die Tests alle funktionieren. Zusätzlich sollte mit Hilfe eines geeigneten Programms die <a href="Testabdeckung" title="Testabdeckung">Testabdeckung</a> ermittelt und geprüft werden, ob die zu ändernde Stelle im Code tatsächlich durch automatisierte Tests geschützt ist. Dies stellt sicher, dass das Programm richtig läuft. Nach Ausführung des Refactoring wird wieder die Testsuite ausgeführt. So kann man einige Fehler beim Refactoring sofort erkennen. Falsch wäre jedoch die Aussage, dass Unit-Tests das Refactoring sicher machen könnten, Unit-Tests senken lediglich die Risiken des Refactorings.

Weiterhin gilt das Prinzip der kleinen Änderungen. Wenn man nur wenig verändert, so kann man zum einen hoffen, auch nur wenig zu zerstören, falls man durch das Refactoring Fehler einträgt (trotzdem können kleine Ursachen große Auswirkungen haben). Zum anderen lassen sich gemachte Fehler dann auch leichter finden.

Meistens kann man komplexe Refactorings, die man plant, in einfache kleine Einheiten zerlegen. Vor und nach jedem Schritt wird wieder durch die Tests die Integrität des <a href="System" title="System">Systems</a> geprüft.

Durch die Verwendung automatisierter Refactoring-Funktionen (wie sie z. B. von <a href="Eclipse_(IDE)" title="Eclipse (IDE)">Eclipse</a> oder <a href="Borland_Delphi" class="mw-redirect" title="Borland Delphi">Borland Delphi</a> ab Version 2005 zur Verfügung gestellt werden) lassen sich ebenfalls Fehlerquellen effektiv ausschließen sowie der eigene Arbeitsaufwand minimieren.

Schließlich gibt es einen Katalog von Refactoring-<a href="Muster" title="Muster">Mustern</a>, die ähnlich wie die <a href="Entwurfsmuster" title="Entwurfsmuster">Entwurfsmuster</a> eingesetzt werden, um Fehler zu vermeiden. Dabei ist in jedem Muster eine Reihe von Parametern definiert. Da wäre erstmal das Ziel des Musters (<a href="Methode_(Programmierung)" title="Methode (Programmierung)">Methode</a> extrahieren, <a href="Klasse_(Objektorientierung)" title="Klasse (Objektorientierung)">Klasse</a> umbenennen etc.) und dazu dann eine Reihe von <a href="Arbeitsanweisung" title="Arbeitsanweisung">Arbeitsanweisungen</a>, die für diese Aktion ausgeführt werden müssen. Viele dieser Muster können heutzutage automatisch von <a href="Werkzeug" title="Werkzeug">Werkzeugen</a> umgesetzt werden. Man trifft als Softwareentwickler nur noch die Entscheidung, welches Muster worauf angewendet wird, um den <a href="Quelltext" title="Quelltext">Quelltext</a> zu verbessern. Es ist jedoch zu beachten, dass die Mechanismen oftmals noch recht fehleranfällig sind. Im besten Fall kommt es durch so verursachte Fehler zu einem Problem beim Übersetzen, aber auch Laufzeitfehler können die Folge sein. Ein umfangreiches, möglichst automatisiertes Testen ist daher nach einem Refactoring immer erforderlich.

<div class="mw-heading mw-heading2"><h2 id="Beispiel">Beispiel</h2></div>

Dieser <a href="Java_(Programmiersprache)" title="Java (Programmiersprache)">Java</a>-Code vor dem Refactoring enthält eine temporäre Variable, die für mehrere Zwecke verwendet wird und einen nichtssagenden Namen besitzt:

<div class="mw-highlight mw-highlight-lang-java mw-content-ltr" dir="ltr"><pre> double x = 2 * (breite + hoehe);

x = breite * hoehe;

</pre></div>

Durch Refactoring wird für jeden der Verwendungszwecke eine getrennte Variable deklariert, die jeweils einen aussagekräftigen Namen trägt:

<div class="mw-highlight mw-highlight-lang-java mw-content-ltr" dir="ltr"><pre> double umfang = 2 * (breite + hoehe);

double flaeche = breite * hoehe;

</pre></div>

Durch weiteres Refactoring können die beiden lokalen Variablen eliminiert werden.

Nachteile:

<ul><li>Bedeutung der Ausdrücke wird unklarer.</li>

<li>Ausdrücke können schlechter im <a href="Debugger" title="Debugger">Debugger</a> angezeigt werden.</li></ul>

Der entstehende Code wird weder besser noch schlechter, da <a href="Compiler" title="Compiler">Compiler</a> seit Mitte der 1990er Jahre <a href="Common_subexpression_elimination" title="Common subexpression elimination">Common subexpression elimination</a> wie auch Live variable analysis beherrschen.

<div class="mw-highlight mw-highlight-lang-java mw-content-ltr" dir="ltr"><pre> System.out.println("Umfang: " + (2 * (breite + hoehe)));

System.out.println("Fläche: " + (breite * hoehe));

</pre></div>

Man könnte die Berechnung auch in eine Klasse verlegen und diese verwenden:

<div class="mw-highlight mw-highlight-lang-java mw-content-ltr" dir="ltr"><pre> Rechteck rechteck = new Rechteck(breite, hoehe);

System.out.println("Umfang: " + rechteck.umfang() );

System.out.println("Fläche: " + rechteck.flaeche() );

System.out.println("Eckenanzahl: " + rechteck.ecken() );

System.out.println("Diagonalen: " + rechteck.diagonale(0,1) );

</pre></div>

<div class="mw-heading mw-heading2"><h2 id="Literatur">Literatur</h2></div>

<ul><li><a href="Martin_Fowler" title="Martin Fowler">Martin Fowler</a>: Refactoring. Wie Sie das Design vorhandener Software verbessern. Addison-Wesley Verlag, München 2000, ISBN 3-8273-1630-8. 2. Auflage Refactoring: Improving the Design of Existing Code, Addison-Wesley 2018, ISBN 978-0-13-475759-9.</li>

<li>Robert C. Martin: <cite style="font-style:italic">Clean Code: Refactoring, Patterns, Testen und Techniken für sauberen Code</cite>. mitp, Frechen 2009, ISBN 978-3-8266-5548-7.<span class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rfr_id=info:sid/de.wikipedia.org:Refactoring&rft.au=Robert+C.+Martin&rft.btitle=Clean+Code%3A+Refactoring%2C+Patterns%2C+Testen+und+Techniken+f%C3%BCr+sauberen+Code&rft.date=2009&rft.genre=book&rft.isbn=9783826655487&rft.place=Frechen&rft.pub=mitp" style="display:none"> </li>

<li>William C. Wake: Refactoring Workbook. ISBN 0-321-10929-5.</li>

<li>Ch. Bommer, M. Spindler, V. Barr: Softwarewartung – Grundlagen, Management und Wartungstechniken. dpunkt.verlag, Heidelberg 2008, ISBN 3-89864-482-0</li>

<li>Joshua Kerievsky: <cite class="lang" lang="en" dir="auto" style="font-style:italic">Refactoring to Patterns</cite> (= <cite class="lang" lang="en" dir="auto" style="font-style:italic">Programmer’s Choice</cite>). 1. Auflage. Addison-Wesley, 2006, ISBN 978-3-8273-2503-7 (englisch, <a rel="nofollow" class="external text" href="http://industriallogic.com/xp/refactoring/catalog.html">industriallogic.com</a> [abgerufen am 14. März 2013] Originaltitel: <cite style="font-style:italic">Refactoring to Patterns</cite>.).<span class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rfr_id=info:sid/de.wikipedia.org:Refactoring&rft.au=Joshua+Kerievsky&rft.btitle=Refactoring+to+Patterns&rft.date=2006&rft.edition=1&rft.genre=book&rft.isbn=9783827325037&rft.pub=Addison-Wesley&rft.series=Programmer%E2%80%99s+Choice" style="display:none"> </li>

<li>William G. Grisworld, William F. Opdyke: The Birth of Refactoring: A Retrospective on the Nature of High-Impact Software Engineering Research in: IEEE Software Vol. 32 (6), November/December 2015 (<a rel="nofollow" class="external text" href="https://www.computer.org/csdl/magazine/so/2015/06">IEEE Computer Society Digital Library</a>).</li></ul>

<div class="mw-heading mw-heading2"><h2 id="Weblinks">Weblinks</h2></div>

<div class="sisterproject" style="margin:0.1em 0 0 0;"><a href="https://de.wiktionary.org/wiki/refactoring" class="extiw external" title="wikt:refactoring">Wiktionary: refactoring</a> – Bedeutungserklärungen, Wortherkunft, Synonyme, Übersetzungen</div>

<ul><li><a rel="nofollow" class="external text" href="http://c2.com/cgi/wiki?WhatIsRefactoring">Was ist Refactoring?</a> – c2.com Artikel (englisch)</li>

<li><a rel="nofollow" class="external text" href="http://www.tornau.name/category/program/refactoring/">Refactoring Motivation, Herleitung und Demonstration in Eclipse</a></li>

<li><a rel="nofollow" class="external text" href="http://www.tutego.com/java/refactoring/catalog/">Übersetzung von Fowlers Refactoring-Katalog</a></li>

<li><a rel="nofollow" class="external text" href="https://mindprod.com/jgloss/unmain.html">Wie wird unwartbarer Quelltext geschrieben?</a> von Roedy Green (englisch)</li>

<li><a rel="nofollow" class="external text" href="https://refactoring.com/">Refactoring</a> von Martin Fowler (englisch)</li>

<li><a rel="nofollow" class="external text" href="http://s3.amazonaws.com/grabbagoftimg/Smells%20to%20Refactorings.pdf">Smells to Refactorings Quick Reference Guide</a> (PDF; 116 kB)</li>

<li><a rel="nofollow" class="external text" href="http://refactoring.com/catalog/">Refactoring Catalog</a> von Martin Fowler</li></ul>

Werkzeuge

<ul><li><a rel="nofollow" class="external text" href="http://bicyclerepair.sourceforge.net/">bicyclerepair</a> Refactoringwerkzeug für Python</li></ul>

<div class="mw-heading mw-heading2"><h2 id="Einzelnachweise">Einzelnachweise</h2></div>

<li id="cite_note-1"><a href="#cite_ref-1">↑</a> Floyd Marinescu, Abel Avram: <cite class="lang" lang="en" dir="auto" style="font-style:italic">Domain-Driven Design Quickly</cite>. Hrsg.: C4Media. InfoQ, 2007, ISBN 978-1-4116-0925-9, S. 57–59 (englisch, <a rel="nofollow" class="external text" href="http://www.infoq.com/minibooks/domain-driven-design-quickly">infoq.com</a> [abgerufen am 7. März 2013]).<span class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rfr_id=info:sid/de.wikipedia.org:Refactoring&rft.au=Floyd+Marinescu%2C+Abel+Avram&rft.btitle=Domain-Driven+Design+Quickly&rft.date=2007&rft.genre=book&rft.isbn=9781411609259&rft.pages=57-59&rft.pub=InfoQ" style="display:none">

</li>

<li id="cite_note-2"><a href="#cite_ref-2">↑</a> <a rel="nofollow" class="external text" href="http://c2.com/cgi/wiki?RefactorMercilessly">Refactor Mercilessly.</a> <a href="Portland_Pattern_Repository" title="Portland Pattern Repository">Portland Pattern Repository</a>, abgerufen am 7. März 2013 (englisch).<span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3ARefactoring&rft.title=Refactor+Mercilessly&rft.description=Refactor+Mercilessly&rft.identifier=http%3A%2F%2Fc2.com%2Fcgi%2Fwiki%3FRefactorMercilessly&rft.publisher=%5B%5BPortland+Pattern+Repository%5D%5D&rft.language=en">

</li>

</ol></div><div><div class="zim-footer">

Dieser Artikel wurde von <a class="external text" title="Zuletzt bearbeitet am 2026-01-08" href="https://de.wikipedia.org/wiki/?title=Refactoring&oldid=263138327">Wikipedia</a> herausgegeben. Der Text ist unter <a class="external text" href="https://creativecommons.org/licenses/by-sa/4.0/deed.de">Creative Commons Attribution-Share Alike 4.0</a> verfügbar, sofern nicht anders angegeben. Für die Mediendateien können zusätzliche Bedingungen gelten.

</div>

</div></div>

</div>

</main>

</div>

</body></html>